-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Controller topology (multitap support) #13499
Conversation
@garbear I had a quick look at windows builds (can only test Windows 7) and on current master 42 |
@Montellese they (game addons not using msvc on windows) are not compile time broken, but runtime broken. |
ff032ed
to
1362c5d
Compare
Reports are in, and most things still work. The following input issues with cores have been identified:
These are most likely core bugs (gee, I'm shocked). In any case, I accidentally merged kodi-game/game.libretro#31 so now I gotta get this in. I'll follow up with another PR if needed. jenkins build this please |
Will be replaced by new player manager.
1362c5d
to
e597e70
Compare
This PR contains the final architecture needed for the Player Manager. Whereas #13374 abstracted keyboards and #13482 abstracted mice, this PR presents an abstraction for multitaps (aka hubs).
The conclusion of the Controller Topology Project is significant because we can, for the first time, model how controllers connect to and map to each other for all of gaming history.
Description
At the highest level, this PR adds a new concept to the Game API: the controller topology. A topology defines how things are connected, so this concept lets the player manager reason about how to automatically connect input devices to the console and to each other. This happens without any user effort.
To give a concrete example, SNES and Genesis consoles only have two ports, but they support up to 5 controllers with a multitap. However, multitaps break some games. We can safely default to 2 controllers, and when a new user joins, the (future) Player Manager automatically swaps player 2 with a multitap, then connects player 2 and player 3 to the multitap's ports.
Controller topologies have been expanded to support daisy-chaining as well. For example, the 3DO had a single port, and up to 8 controllers could be daisy-chained together. This will be reflected in the Player Manager where it's impossible to have a player 2 without a player 1.
Finally, a distinction is made between the physical topology and logical topology. The physical topology defines how controllers physically connect together. For example, you can plug a multitap into a multitap. The logical topology defines a subset of those connections that the emulator's logic supports; obviously no emulator allows a multitapped multitap, so even though this is physically possible, it is disallowed.
Motivation and Context
Like all other input features, this came about while trying to automate a part of the libretro API. While awesome at what it does, the libretro API makes emulation horribly inaccessible to users who don't have any concept of what a RetroPad or a Multitap is.
How Has This Been Tested?
Configuring multitaps requires a Player Manager, which is still in progress. For now, game console ports are hard-coded to accept the first controller specified by their topology.
Tested with controllers, keyboards and mice and various emulators on Linux and OSX.
Android requries kodi-game/kodi-game-scripting#19 to fix game add-ons.
Game add-ons on Windows broke after #13140. I'd appreciate help fixing this.
Screenshots (if appropriate):
A (theoretical) example of how depth-first controller-to-player assignment works:
Types of change
Required PRs